-
Notifications
You must be signed in to change notification settings - Fork 9.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
consolidate version information #32973
Conversation
33a024a
to
891133f
Compare
891133f
to
a79795e
Compare
a79795e
to
54b875a
Compare
fb53e70
to
d09db87
Compare
I've thrown a backport label on here, but I'm very much open to the idea that we should not backport this build change to the 1.4 series, and instead let it be the default for 1.5 onwards. |
FWIW the legacy release process includes some non-robust regular expressions looking for the I don't think it particularly matters since we have no intention to return to using the legacy process, but if we do end up needing to use the legacy process in any branch where this has been merged we should be sure to check that what it built has a correct version number compiled into it. (In practice I think the e2etests would catch it, because running |
Excellent callout! I didn't preemptively open a PR over in the private repo since we haven't yet agreed that the path proposed in this PR is a good one, but I will certainly do that as followup. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of curiosity I triggered a run of the build workflow against this branch to see what it would do: https://github.com/hashicorp/terraform/actions/runs/4671153628
This all makes sense to me, so I'm cautiously approving it but with the caveat that I'm not an expert on all of the wiring that leads up to running the scripts you modified here and so although I think I can see how the information flows, it might be worth getting a second opinion from someone who was more involved in setting this up.
|
||
### Experimental Features | ||
|
||
Experimental features of Terraform will be disabled unless `main.experimentsAllowed` is set to `yes`: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe worth calling out here that we only do this for alpha release builds, and recommend third-party distributors follow that same convention to reduce confusion.
BUILDING.md
Outdated
|
||
## Go Options | ||
|
||
The Terraform release process uses the Go toolchain defaults for the current operating system and processor architecture. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we have some special rules for setting CGO_ENABLED
differently on different platforms, which we should perhaps describe here in case the reader is trying to produce a binary that has identical behavior to the official release.
(In particular, if folks build a Linux binary on Linux without setting CGO_ENABLED=0
then they'll build an executable that relies on their system's specific libc, whereas our official releases have CGo disabled so that they can run on systems with any libc.)
SemVer = semVerFull.Core() | ||
Version = SemVer.String() | ||
|
||
if dev == "no" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there is already a prelease set in VERSION (e.g -alpha
) would the desired behavior for local builds be that this is dropped in favour of -dev
or the other way around?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dropping any existing prerelease in favor of -dev
! That's been our convention previously, so seemed just as well to stick with it for now.
Instead of having two different places where we keep the current version which must be manually kept in sync, let's use the same one that the release process uses (version/VERSION). Local builds will remain tagged with -dev by default, and we'll disable this behavior with a linker flag at release time.
d09db87
to
1e2a6be
Compare
I triggered a build from this branch and verified that the binaries produced by it report the correct version number: https://github.com/hashicorp/terraform/actions/runs/5581974639#artifacts |
Reminder for the merging maintainer: if this is a user-visible change, please update the changelog on the appropriate release branch. |
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
Now that we've switched to our new build system and are using
version/VERSION
as the canonical way to discover versions during the build process, it is unfortunately rather easy forversion/VERSION
and the version defined inversion/version.go
to drift out of sync, which causes unfortunate problems like #32963 at release time.This PR proposes making
version/VERSION
the canonical source for version info at all times, using a file embed. To make things less confusing in local development, we'll keep the-dev
prerelease by default and set the expectation that release builds, whether ours or a third-party build process, must specifically mark themselves as such via a linker flag in order to report the correct version.Target Release
1.6.x